-
Notifications
You must be signed in to change notification settings - Fork 14
Add close-channel
command to the CLI
#65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Thanks for assigning @jkczyz as a reviewer! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for contributing!
ldk-server-cli/src/main.rs
Outdated
force_close, | ||
force_close_reason, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a commit updating handle_close_channel_request
to only allow force_close_reason
when force_close
is Some(true)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change applied as requested, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... I was thinking we should do this on the server side. But I don't have a problem with doing it here (cc: @tnull any preference?). But we should probably error if force_close_reason
is set but force_close
isn't rather than just ignoring it. See Commands::Bolt11Receive
handling for an example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense! I think the validation should be included in handle_close_channel_request
on the ldk-server
, since it would also cover requests made through the API and return proper errors there as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, we should probably also validate and error on the server side if the user supplies an arguement that doesn't fit the intended use case. Alternatively, we could split the channel closing API in a mutual close and force close variant, which would ensure we always just set the right fields for the right calls.
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
🔔 2nd Reminder Hey @jkczyz! This PR has been waiting for your review. |
Split channel closing into separate endpoints for mutual and force close
|
ldk-server-cli/src/main.rs
Outdated
#[arg(short, long)] | ||
counterparty_node_id: String, | ||
}, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: remove empty line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
string user_channel_id = 1; | ||
// The hex-encoded public key of the node to close a channel with. | ||
string counterparty_node_id = 2; | ||
// The reason for force-closing, can only be set while force closing a channel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"can only be set while force closing a channel" isn't needed anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
ldk-server/src/api/mod.rs
Outdated
pub fn parse_user_channel_id(id: &str) -> Result<UserChannelId, LdkServerError> { | ||
Ok(UserChannelId(id.parse::<u128>().map_err(|_| { | ||
LdkServerError::new(InvalidRequestError, "Invalid UserChannelId.".to_string()) | ||
})?)) | ||
} | ||
|
||
pub fn parse_counterparty_node_id(id: &str) -> Result<PublicKey, LdkServerError> { | ||
PublicKey::from_str(id).map_err(|e| { | ||
LdkServerError::new( | ||
InvalidRequestError, | ||
format!("Invalid counterparty node ID, error: {}", e), | ||
) | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these need to be pub
? IMO, we should just leave these in close_channel.rs
and not make a separate file for handle_force_close_channel_request
. There's enough in common that it can go in close_channel.rs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved handle_force_close_channel_request and the shared parsing functions into close_channel.rs as suggested. Also removed the unnecessary pub modifiers.
Introduce ForceCloseChannelRequest and ForceCloseChannelResponse to the API, implement the handle_force_close_channel_request function, and register the new endpoint in the service router.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed and tested this. Looks good to me.
CLI: Add support for
close-channel
commandThis adds a simple
close-channel
command to the CLI interface.It reuses the existing
close_channel
method fromldk-server-client
.Closes #55.